home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000138_owner-urn-ietf _Thu Oct 31 13:38:28 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA17414 for urn-ietf-out; Thu, 31 Oct 1996 13:38:28 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA17409 for <urn-ietf@services.bunyip.com>; Thu, 31 Oct 1996 13:38:25 -0500
  3. Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA26880  (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 13:38:21 -0500
  5. Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id KAA21600; Thu, 31 Oct 1996 10:36:44 -0800 (PST)
  6. Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id KAA06895; Thu, 31 Oct 1996 10:37:00 -0800 (PST)
  7. Date: Thu, 31 Oct 1996 10:37:00 -0800 (PST)
  8. From: Terry Allen <tallen@fsc.fujitsu.com>
  9. Message-Id: <199610311837.KAA06895@ishtar.fsc.fujitsu.com>
  10. To: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com
  11. Subject: Re: [URN] HTTP resolution protocol
  12. Sender: owner-urn-ietf@services.bunyip.com
  13. Precedence: bulk
  14. Reply-To: Terry Allen <tallen@fsc.fujitsu.com>
  15. Errors-To: owner-urn-ietf@bunyip.com
  16.  
  17. A few comments, mostly re coordination with the Framework document:
  18.  
  19. | 3.1  N2L (URN to URL):
  20. | The request is encoded as above. The URL MUST be returned in a Location:
  21. | header for the convienience of the most common case of wanting the resource.
  22. | A 30X status line SHOULD be returned. HTTP/1.1 clients should be sent the
  23. | 303 status code. HTTP/1.0 clients should be sent the 302 (Moved temporarily)
  24. | status code unless the resolver has particular resons for using 301
  25. | (moved permanently) or 304 (not modified) codes.
  26.  
  27. It would be nice to have a brief explanation of why these are
  28. the right responses, perhaps recapping what will be in the
  29. Framework document.
  30.  
  31. |                               Figure 1
  32. |                Simple format for returning multiple URLs
  33. | 
  34. | [Do we need to have a continuation character for *very* long lines? 
  35. |  I tend to think not.]
  36.  
  37. Might be useful; there will be a significant proportion of long lines.
  38.  
  39. | 3.4  N2Rs (URN to Resources):
  40. | This resolution service returns multiple instances of a resource,
  41. | for example, GIF and JPEG versions of an image. The judgment about
  42. | the resources being "the same" resides with the naming authority that
  43. | issued the URN.
  44.  
  45. All the instances that suit the Accept info the client has sent?
  46. Does that leave us with nothing between asking for one instance
  47. (N2R) and all (N2Rs), or is there some way to quality the request
  48. so that one receives no more than, say, 13 instances?  (Happy
  49. Halloween!)
  50.  
  51. | 3.6  N2Ns (URN to URNs):
  52. | ------------------------
  53. | 
  54. | While URNs are supposed to identify one and only one resource, that
  55. | does not mean that a resource may have one and only one URN. For
  56. | example, consider a resource that has something like
  57. | "current-weather-map" for one URN and "weather-map-for-datetime-x" for
  58. | another URN. The N2Ns service request lets us obtain lists of URNs that
  59. | are believed equivalent at the time of the request. As the weathermap
  60.  
  61. The example implies, "lists of URNs that are believed to name equivalent
  62. resources at the time of the request", which agrees with the language
  63. in the next para.
  64.  
  65. | example shows, some of the equivalances will be transitory, so the
  66. | result should not be cached.
  67.  
  68. | The request is encoded as above. The result is a list of all the
  69. | URNs, known to the resolver, which identify the same resource as the
  70. | input URN. The result shall be encoded as for the N2Ls request
  71. | above. The original URN may appear in the list of returned URNs.
  72.  
  73. | 3.8  L2Ls (URL to URLs):
  74. | ------------------------
  75. | 
  76. | The request is encoded as described above. The result is a list of
  77. | all the URLs that the resolver knows are associated with the resource
  78. | located by the given URL. It is returned in a text/plain body encoded
  79. | as described above.
  80.  
  81. "Associated" is awfully broad.  The Framework document will clear up
  82. what associations are intended, right?
  83.  
  84.  
  85. Regards,
  86.  
  87.     Terry Allen    Fujitsu Software Corp.    tallen@fsc.fujitsu.com
  88. "In going on with these experiments, how many pretty systems do we build,
  89.  which we soon find outselves obliged to destroy?" - Benjamin Franklin
  90.   A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html